Skip to content

Catalog: add the RFC 9449 multi-header invalid_dpop_proof carve-out - #2

Open
RobertoIskandarani wants to merge 2 commits into
mainfrom
rob/dpop-multi-header-carve-out
Open

Catalog: add the RFC 9449 multi-header invalid_dpop_proof carve-out#2
RobertoIskandarani wants to merge 2 commits into
mainfrom
rob/dpop-multi-header-carve-out

Conversation

@RobertoIskandarani

@RobertoIskandarani RobertoIskandarani commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

What

Adds a dpop_multi_header row to the error_scenarios of rfc6750-error-response-must-map-error-codes, plus RFC9449 in that case's standard_refs and a rationale note scoping the carve-out.

- error_type: "dpop_multi_header"
  expected_error_code: "invalid_dpop_proof"
  expected_scheme: "DPoP"

Why

RFC 9449 §4.3 #1 requires that a request carry not more than one DPoP header field. Unlike the other DPoP proof-validation failures — which RFC 6750 §3.1 maps to error="invalid_token" — RFC 9449 §7.1 prescribes error="invalid_dpop_proof" for this rejection, still on the DPoP scheme.

The catalog currently models only dpop_error → invalid_token / DPoP, so SDKs implementing the §4.3 cardinality check have nowhere to pin a conformance assertion for the divergent error code. The rust-sdk already carries the mapping with unit coverage and a deliberate carve-out comment in its catalog-pinned conformance case, deferred until this row exists; other SDKs implementing §4.3 hit the same gap.

Once merged, downstream SDK conformance suites can restore the assertion inside the catalog-pinned case.

@RobertoIskandarani RobertoIskandarani self-assigned this Jul 28, 2026
@RobertoIskandarani
RobertoIskandarani requested review from a team, dbauthplane and muralx July 28, 2026 19:59
@RobertoIskandarani
RobertoIskandarani force-pushed the rob/dpop-multi-header-carve-out branch from 4b60185 to f6b7c09 Compare July 28, 2026 20:04
The www_authenticate error-mapping case pinned every DPoP failure to
invalid_token. RFC 9449 section 7.1 prescribes invalid_dpop_proof for
the section 4.3 multi-header rejection; add that row as the one DPoP
carve-out, leaving the other proof failures on invalid_token.
@RobertoIskandarani
RobertoIskandarani force-pushed the rob/dpop-multi-header-carve-out branch from f6b7c09 to 59d66d9 Compare July 29, 2026 13:02
muralx
muralx previously approved these changes Jul 31, 2026
…ode mapping

The rfc6750-error-response-must-map-error-codes scenario table asserted
only dpop_error → invalid_token + DPoP; it was under-specified for the
bearer-only case. DPoPNotSupported is a DPoPError subclass but the
resource is bearer-only, so its WWW-Authenticate challenge uses the
Bearer scheme with invalid_token (RFC 6750 §3), not DPoP. Add the row
and note the carve-out in the rationale so every SDK maps it uniformly.
@RobertoIskandarani

Copy link
Copy Markdown
Contributor Author

Added commit c00114f: a dpop_not_supported → invalid_token + Bearer row to the rfc6750-error-response-must-map-error-codes scenario table (alongside the dpop_multi_header row this PR introduces), plus a rationale note.

This closes the catalog carry-over flagged in the cs-sdk error-mapping review: the scenario table previously asserted only dpop_error → invalid_token + DPoP, which is wrong for the bearer-only case. DPoPNotSupported is a DPoPError subclass, but because the resource is bearer-only its WWW-Authenticate challenge uses the Bearer scheme with invalid_token (RFC 6750 §3), not DPoP — verified against the reference SDKs (www_authenticate/AuthErrorResponse both map it to Bearer + invalid_token).

make validate passes (104 cases, no new case IDs — SDK alignment is unaffected).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants